Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / networking / terms / kermit / c / rmlinf.doc < prev next >

Wrap

Text File | 1988-08-16 | 31.9 KB | 720 lines

File RMKINFO.DOC ---------------- 10th July 1985. C. J. Kennington Research Machines Ltd. Mill Street OXFORD. Research Machines Kermit for 480Z & Nimbus ------------------------------------------ 0. Overview & Status ----------------- RM Kermit is an implementation of the KERMIT file-transfer protocol to run on RML 480Z and Nimbus computers. Kermit is a file-transfer system developed by the University of Columbia, New York, and implemented on a large number of both mainframe and micro computers. It is fully described in the Kermit User Guide, a shortened version of which is included on this disk. In the rest of this note, familiarity with the contents of the User Guide is assumed. Complete copies of both the User Guide and the Kermit Protocol Manual are available from: Center for Computing Activities Columbia University New York, N.Y. 10027 at $10 (ten dollars) apiece. RM Kermit used as a starting-point the (1983) C-coded version for Unix systems, published as an appendix to the Protocol Manual The status of this is not "Public Domain", but "Copyright - freely available". The status of RM Kermit is "Copyright Research Machines and U. of Columbia", but free permission is given to copy the binary version and use it. The high-level program (i.e. that part which is coded in C) is also made freely available, as requested by Columbia; the low-level routines which drive keyboard, screen and the various communications devices on 480Z and Nimbus are RML copyright, and may not be further distributed without permission from RML. RM Kermit Capabilities At A Glance: Local operation: Yes Remote operation: No User Interface: Menu-driven Transfers text files: Yes (with CR/LF validation) Transfers binary files: Yes (image or prefixed) Wildcard send: Yes ESC interruptions: Many Filename collision avoidance: Yes (with filename validation) Can time out: Yes (fuzzy) 8th-bit prefixing: Yes Repeat count prefixing: Yes Alternate block checks: No Terminal emulation: Yes (dumb) Communication settings: Most (depends on hardware) Transmit BREAK: Yes (fixed length) IBM communication: No Transaction logging: No Session logging: No Raw upload/download: No Act as server: No Talk to server: Yes Advanced commands for servers: Some Local file management: Yes Handle file attributes: No Command/init files: No Printer control: No 1. Hardware Supported and Program Versions. ---------------------------------------- RM Nimbus Kermit supports communications via the Nimbus Auxiliary Port in RS422 mode and via the Piconet Serial Interface Module. Support for the RS232C Data Communications Controller will be added in due course. For a note on connection of the RS422 port to RS232 equipment, see Appendix I. RM 480Z Kermit has been designed specifically to make use of the facilities of the Mark II 480Z (ROS level 2.?), but will run with a few minor imperfections on earlier 480Zs. This version supports three quite different configurations. On a Link-480Z connected to a Chain Network, without local disks, the communications-line is plugged into the SIO4 port on the back of the 480Z. Where local disk units (MD1, MD2 or MQ2) are connected to the 480Z, they also use this port; the communications-line is therefore plugged into the SIO4 port on the back of the Disk Unit ("IDC") and all communications are relayed by the processor in the IDC. If both an IDC and Chain Network are in use, the port on the IDC is once again used but the program logic is different. Quite different code is used for driving the communications in these three configurations, and it is essential that the correct version of 480Z Kermit is loaded. RM Kermit will not run on 380Z, but a version for 380Z (double-density disk models only) is available from the Computer Centre at Oxford University. 480Z Kermit consists of a single .COM module, whose name is: dKMITnn.COM Nimbus Kermit consists of a single .EXE module whose name is: cKMITnn.EXE where: d = I for IDC (local disks), N for Network disks, X for IDC and Network; c = A for communications by Aux port (RS422), P for communications via Piconet SIM (RS232C), D for communications via DCC (RS232C); nn = decimal part of version-number. The versions current at the time this is written are IKMIT22.COM (480Z for local disks), NKMIT22.COM (480Z for network disks), XKMIT13.COM (480Z for both local and network disks), AKMIT22.EXE (Nimbus via Aux port) and PKMIT22.EXE (Nimbus via Piconet SIM). 480Z silicon disk and shared disk systems have not been tested. The header information displayed when Kermit is loaded identifies the type of communications for which the version is designed. You are advised to check this before proceding! 2. Program Loading and Startup. ---------------------------- Kermit (the appropriate version) is loaded from disk in the normal way by a command such as: d:NKMIT21 When loaded, Kermit puts up a 4-line heading which identifies it and provides a display for monitoring file-transfer activity. This display, with a divider underneath it, occupies the top 5 lines of the screen, leaving 19 lines for general use (20 on Nimbus). An additional header is placed on lines 20-22 whenever command-mode is entered. Included in this second header is a field "Communications:", which will be set to either "Direct" or "via Disks" (480Z), "by Aux" or "via Piconet" (Nimbus), showing which version has been loaded. In the Nimbus Piconet version only it is necessary to select the piconet address of the SIM before the program proper starts; this can be in the range 1-8 (the recommended addresses for SIMs). The prompt for this address must be answered by a single digit or ENTER (which defaults to 1); invalid entries are rejected. If the SIM is not found at this address, the program immediately aborts. 3. Line-Speed and Performance. --------------------------- 480Z Kermit handles line-speeds from 75 to 19200baud; the same speed must be used both for transmission and receipt of data. Nimbus Kermit will handle line-speeds from 110 to 9600baud via tha Aux port or 110 to 2400baud via the Piconet SIM. In the both versions, during CONNECT, data can be displayed on the screen at up to 1000 char/sec depending on the proportion of line-feed characters in the data. Kermit's data-reception is buffered, so that if the screen falls behind the data received, it will catch up without data loss when the incoming flow pauses. (The size of the receive buffer is 600 bytes; data will be lost if the screen falls this much behind.) Flow-control by CTS/RTS, XON/OFF or ENQ/ACK is available on the 480Z version, but is not needed for running Kermit transfers. Net transfer rates during SEND and RECEIVE operations are about 60% of the basic line-speed, e.g. some 600 char/sec at 9600baud. This performance will degrade if any debugging or listing display is switched on, or if the responses from the mainframe are less than prompt, or if there are delays in the connecting network. Contention for the Winchester disks on an RML Network can also reduce throughput. 4. Facilities Supplied and User Interface. --------------------------------------- RM Kermit is still under development. The current (July 1985) version supplies the normal communications facilities of a local-only Kermit, but with an easy-to-use menu-driven interface for commands etc. Control of RM Kermit is by menus. The main menu is displayed when the program is loaded, and again whenever any major activity is completed. The various facilites of the program are listed, and a cursor shows which one is currently selected. The up and down arrow-keys and F1 & F3 keys are used to move this cursor; help information is automatically displayed at the bottom of the screen. When the desired facility has been selected, RETURN / ENTER causes it to be started. When any activity is complete, Kermit returns automatically to the main menu (in some cases after a RETURN has been entered, so that information on the screen is not wiped before it can be read). At almost any time a precipitate return to the main menu may be caused by hitting the F4 key and entering K in response to the special prompt displayed; entering Q rather than K will cancel the Kermit program (after seeking confirmation). If a file-transfer is in progress, there may be a pause while this is suitably aborted in cooperation with the mainframe Kermit. In modes other than CONNECT, the ESC key has the same effect as F4. On Nimbus the F9 & F8 keys generate the character-pairs ESC K and ESC Q respectively, producing the same effects with a single keystroke. In many modes, an isolated RETURN will also cause reversion to the main menu. Entering CTRL-C when any input is expected (e.g. file-names) usually causes cancellation of the immediate activity; it also cancels displays in disk-maintenance mode. When in CONNECT mode, all the normal keys (including ESC) and key-combinations will transmit the expected characters to the mainframe. In addition, F2 will send a TAB character. The 4 arrow-keys (up, down, right & left) send control-characters 0bH, 0aH (LF), 18H and 08H respectively. DELT/DEL sends 7fH. Most other special keys will send either nothing or character-combinations which are meaningless. Data transfers may be carried out in two ways. If the remote mainframe is running a simple Kermit, this must be set to either send or receive files and the corresponding Receive or Send mode then used on RM Kermit. If the mainframe Kermit has server capability, it may be set going in this mode and RM Kermit then used in Commands to Server mode. The way in which data is handled depends on whether 7-bit, 8-bit-image or 8th-bit-prefixed mode has been selected (see below). In 7-bit mode, all data is sent and received as 7-bit ASCII characters. In image mode it is sent and received as 8-bit characters, but there is no guarantee that the communications path may not have altered the 8th-bit values en route; if this happens the received file is likely to be garbage, and no warning message will be given. In 8th-bit-prefixed, special encoding is used to transfer the setting of the 8th bit of every character, but this slows down the transfer. In general, for text files, 7-bit mode should be used. To transfer binary files image mode may be used with direct local communications; prefixed may be used over any communications path provided the mainframe Kermit will cooperate. Both these last modes may require special instructions to be given to the mainframe Kermit. In 7-bit mode only, special processing is used on all incoming CR and LF characters, particularly CR/LF and LF/CR pairs to ensure that all lines of text are terminated by a CR/LF pair before being stored in the received file. This is to avoid problems which have been encountered with mainframe systems which use different conventions to terminate lines in text files. 8-bit transfers are assumed to be binary and are stored as received. RM Kermit implements repeat-count-prefixing, which enables strings of repeated characters to be compressed in transmission. This facility is always active but has to be accepted by the mainframe Kermit before it can be made use of. Its use it may speed up transfers considerably, but does not affect the data received in any other way. On Nimbus, care must be taken with the "CAPS LOCK" and "NUM LOCK" keys. These are "push-push" switches, i.e. they alter the overall state of the keyboard without remaining locked down or giving any other indication. The effect of the CAPS-LOCK should be obvious. NUM-LOCK however nullifies all the special sequences which have been installed in the arrow and F keys; this is very inhibiting and non-obvious. If the arrow and F keys are not responding as expected, try hitting NUM-LOCK! 5. Help Systems & Confirmation. ---------------------------- The main & server-command menus display help-texts automatically. When in the parameter-setting menu, help may be obtained at any time by entering "?" (for specific help) or "H" (for general help). Help on the possible F4 break-in actions may be obtained at (almost) any time by the sequence "F4 ?". The amount of text displayed is limited since no separate help-file on disk is currently implemented. There are a number of points in controlling RM Kermit where action can be requested which is potentially catastrophic (e.g aborting a file transfer). In these cases the query "Yes?" will be displayed. If the user's response is "Y", "y" or RETURN/ENTER, then the action will be taken; any other character will prevent the action from being carried out. 6. CP/M & MSDOS File-Handling. --------------------------- All names of files in CP/M and MSDOS are inherently upper-case. When using RM Kermit they may be entered in either upper or lower case and will be translated to upper before action is taken; similarly if lower-case characters occur in filenames received from the mainframe Kermit (which they should not), they will be converted to upper-case. Filenames under CP/M or MSDOS are of the format: d:name.ext where: d = disk-letter, name = filename, 1-8 alphanumerics, ext = extension, 0-3 alphanumerics. If the extension is null, the dot preceding it is omitted. All alphabetics are upper-case. If the disk-letter is omitted, so is the colon following it; in this case the default-disk is used. The name and extension normally consist only of letters, digits and "$"; although a few other special symbols are not illegal, their use is discouraged. (Under MSDOS only, the names of files whose extension is null may need to have the dot appended before MSDOS utilities will recognize them correctly.) Two wildcard characters are accepted whenever a filename is specified by the user. A "?" in any position matches any valid character (including blank/null); a "*" is the equivalent of entering enough ?s to complete either the filename or the extension. (In general neither CP/M nor MSDOS diagnose names which are too long; surplus characters are merely ignored. The Kermit name-input routines, however, do check for such overlong names.) In MSDOS the file may also have a "path"; in CP/M it may have a "user-number". RM Kermit takes no account of these; the user must make sure that path or user number are correctly set before the transfers commence (which can be done in Disk-mode.) Filenames are sent without disk-letters. Received filenames are processed to remove any disk-letter and ensure that they conform to this format. Invalid characters are dropped (including special characters other then "$"). A single dot is accepted as terminating the filename and starting the extension. For names (not including a dot) of between 9 and 11 characters, the first 8 characters are taken as the name and the next 1-3 as the extension. Surplus characters (beyond 11) are dropped. If processing results in a null name, the file is stored as "INVALID.NAM". The same processing is applied to overriding names specified for files received, except that the disk-letter is respected. If a disk-letter only (which must be entered with its normal trailing colon) is given as an override, the incoming file is stored under its own name but on this disk. If overriding names are entered but more files are sent by the remote Kermit than names entered, then the extra files will be stored under their received names. Filename collision avoidance (which ensures that an incoming file cannot overwrite an existing one of the same name without warning) is under control of the user. By default, collisions are avoided, by modification of the incoming file's extension, in cases where a file of the same name already exists on the specified disk. Alternatively, the File-Collision parameter may be changed to overwrite existing files, to reject incoming files which would cause collisions, or to query the user as to whether overwriting is permissible. The modification is to replace the second character of the extension by "$" and/or to increment its last character by 1. If the extension is null, this algorithm is applied to the last letters of the name; if extension or name is less than 3 characters long, it is extended to 3 characters before the modification is applied. If the name after modification still matches an existing file, the same algorithm is reapplied to the modified name. If after successive modifications the result is an invalid name (e.g. if the extension was originally .A$9 and the last character has been incremented to ":"), the transfer is refused. 8. Parameter Setting and Displaying. --------------------------------- All adjustable parameters may be inspected and set in Parameter Mode (entered from the main menu); the current and all possible values may be displayed. A few of these parameters may also be set by low-level breakins. In the list below, if a key-letter is given, this is what is to be entered after ESC/F4 when breaking-in. Baud-Rate Sets line-speed to one of the permitted values. E Local Echo If ON, all characters sent in Connect Mode are also displayed on the screen. File Collision See above for the meanings of the settings of this parameter. Flow-Control Selects either no flow-control, or CTS-RTS, of XON/OFF (Tandem), or ENQ/ACK, or combinations of these. 8th-bit If off, 7-bit characters are handled; if "image" 8-bit characters are sent and received (image-mode); if "prefixed", then 8th-bit prefixing will be attempted. L List/Debug Normally set to display a dot for each good block sent/received (and a letter for each bad block). May be set OFF, in which case nothing is displayed to show progress of the transfer; or may be set to value 2 to list all data as it is sent/received (this is not advised on binary files). Extra settings (values 3-6) permit increasing amounts of debug information to be displayed on the screen as blocks are sent and received. N Slow-Network If ON, steps are taken to discard any duplicate packets which may have been buffered by the network. This is OFF by default, since if it is used with high-speed (back-to-back) connections it may cause the loss of blocks of genuine data. Packet-Size Defines an overriding maximum to the size of packet which will be sent or received. Page-Wait Normally OFF. If set to a number of lines, then during Connect or Disk-Utility Modes the screen will wait for an input character (which is then discarded) after every so many lines. (The legend "[more]" is displayed at the end of the last line, if there is room, while waiting for this input.) Parity Defines the parity to be generated as 0 = none, 1 = odd, 2 = even, 3 = mark; applies to data sent. (There is no provision to check the parity of data received; this is stripped to 7-bit unless image or 8th-prefixed has been set.) For image transfers, parity must be 0. In modes where loss of information is not likely to be caused, ESC-P also calls up the main parameter-setting menu so that any parameters may be changed. Exit from this menu (by RETURN) picks up whatever activity was interrupted. On any particular version of RM Kermit, there will be parameters or values on the menu which are not implemented. An attempt to use such a parameter results in a warning message and no other action. 9. Other Break-Ins. ---------------- At most times either the F4 or ESC keys cause a break-in which interrupts the current activity; CTRL-C usually does the same; all other normal keys have no effect. In Connect mode, only the F4 key causes a break-in, since ESC is a valid character to be sent to the mainframe (see above). As well as the parameters that may be set by break-in after F4, various other actions can be requested. For any given mode, only some of them are valid; "F4 ?" at any time will show which are and are not currently possible. The possible actions, and the break-in key-letters which call them, are: ? - Get Help * A - Abort current transfer B - Send line-break, approx 1 second C - Clear screen F - Call "Front-Panel" (480Z only) H - Get general Help K - Return to Kermit Main Menu P - Call Parameter-Setting Menu * Q - Quit - Cancel Kermit program R - Enter Receive Mode S - Enter Send Mode T - Simulate Timeout / Send NAK Z - Toggle DTR up/down * these actions request confirmation before proceding. Note particularly that after F4 causes a breakin, all other activities (except interrupt-driven data reception) are inhibited. If this is done during a file transfer, timeouts will occur; if the period of inactivity is prolonged, the transfer will probably abort. On Nimbus, the extra F-keys are programmed so that they send the following sequences: F5 ` back-quote character F6 ESC S enter Send mode F7 ESC R enter Receive mode F8 ESC Q Quit (after confirmation) F9 ESC K back to main menu F10 ESC B send Break In addition, PG UP and PG DN are programmed to correspond with F1 & F3 (up and down page), and END is also programmed as down page. The pound- sign (shift-3), which sends a non-ASCII character when in its standard state, is reprogrammed to send back-quote (`). 10. Terminal Emulation. ------------------- In Connect Mode, RM Kermit does not attempt to emulate any particular screen-editing terminal. Its responses to control-characters are a small subset of those defined for the 480Z in the RML Firmware Reference Manual. It is always in "scroll" mode, i.e. any attempt to write text beyond the right or bottom margin causes wrap-around and/or screen scrolling. The cursor reponds to CR by inserting a newline (but special code traps CR/LF and LF/CR pairs so that each produces only a single newline). The cursor moves up, down, right or left in response to the characters transmitted by the arrow-keys (see above). It is assumed that if a substantial terminal session is required with a mainframe, the RML VT100 Terminal Emulator Program will be used rather than Kermit. 11. Disk Utility Mode. ------------------ This mode emulates (in a system-independent manner) the basic file-control functions of CP/M or MSDOS. The commands available are:- * CHAnge - Reset all disk drives; DELete - Remove named files; DIRectory - List file directory; ERAse - synonym for DELete; HELp - Print help-text; * REName - Rename one file to another; TYPe - List a file on the screen; UPAth - Show user environment; * USEr - Set user-number; d: - Change default drive to "d"; ? - synomym for HELp. The starred functions differ between CP/M and MSDOS, and the action is altered to resemble that of the OS being used. Only the first 3 letters of each command need be entered. Wildcards (? = any character, * = any string of characters) are accepted, but since the code is emulating the OS they may not work in quite the same way. Note that on a 480Z network system, wildcards take a considerable time to interpret. ERAse (DELete) lists all the files it proposes to delete and requests confirmation before doing so. Only one filename (possibly with wildcards) may be entered for a single ERAse. 12. Sending Commands to Server-Kermits. ----------------------------------- If the mainframe Kermit is a "Server", it is capable of performing a range of activities on command from the local (micro) Kermit. Commands of this nature may be sent if the item "Commands to Server" is selected on the RM Kermit Main Menu. Since there are very many different mainframe Kermits, it may be necessary to consult the documentation or help-texts of the one being used in order to find out which server commands are accepted by it. If an unacceptable command is sent, most server Kermits will return a sensible error-message. The commands which may be sent are shown on a "Commands to Server" menu. This provides the following options:- a. Kermit Commands. ---------------- In this case a line of text entered by the user will be sent to the mainframe Kermit for execution as though it had been typed in (to the mainframe Kermit) when in Connect mode. b. Mainframe Commands. ------------------- In this case a line of text entered by the user will be submitted by the mainframe Kermit to the mainframe Operating Sytem for action as though it were a normal command to the OS. c. Get Files. ---------- In this case the line of text entered by the user should be a list of files for the mainframe Kermit to send to the micro. The user should remember that wildcards (* & ?) will be sent to the mainframe "as is"; whether this is useful depends on the mainframe Kermit. d. Send Files. ----------- This is the equivalent of "Send Files" from the Main Menu, and the list of files should be entered in the same way. e. Cancel Mainframe Kermit. ------------------------ This sends an error-message to the mainframe Kermit, which should force it to abort and leave you connected to the mainframe Operating System (in Connect mode). f. Logout from Mainframe. ---------------------- This sends a "BYE" message to the mainframe Kermit, which should cause it to disconnect you and terminate your mainframe session. g. Back to Main Menu. ------------------ No message is sent to the mainframe; RM Kermit returns to the Main Menu to permit further actions. h. Terminate Kermit Run. --------------------- No message is sent to the mainframe; RM Kermit is cancelled and control returns to CP/M or MSDOS. The last 4 actions do not require any additional input from the user. The user input to "Send Files" consists of filenames as known to the micro. For the first three actions, the text input by the user will be sent to the mainframe Kermit without any editing at all; its format must therefore be exactly what the mainframe requires, and this will differ according to the make of mainframe and type of server-Kermit running on it. For details, reference should be made to the documentation of the mainframe Kermit. (Note particularly that text will be sent in upper or lower case as entered; this is highly significant to certain mainframes.) The first two actions may be expected to generate a smaller or greater amount of data in reply. This is displayed on the 480Z/Nimbus screen. It is not buffered on disk, so if it is held up by paging, the mainframe Kermit is likely to time out. A risk of cancellation of the whole mainframe session exists if this output is held up for more than a minute or so. (These facilities have not been subject to the same amount of testing as the Connect-Send-Receive facilities; reports of bugs, omissions or problems would be very welcome.) 13. Adaptation of RM Kermit. ------------------------- RM Kermit has been produced to run on the 480Z and Nimbus micros, under CP/M and MSDOS respectively. The C-code which controls the overall program behaviour is however not believed to depend on specific hardware and could be adapted to run on other systems. RML will permit the code to be used for this purpose (since it is a fundamental principle of the Kermit world that all Kermit code is to be made freely available), but are not in any way liable for anything which may result from such actions. The way in which this code interfaces to the low-level routines which drive the keyboard, the screen and the communications port in a way is defined in file RMKIFACE.DOC. Techniques and tools for handling the code and modules of RM Kermit are described in file RMKGEN.DOC. Chris Kennington. Appendix -------- Connection of Nimbus RS422 Port to RS232 Equipment. --------------------------------------------------- RS232 & RS422 use different signalling systems and voltage levels, but in practice most RS232 equipment will connect to and function with the Nimbus RS422 port. An interworking standard is in fact defined in an annexe to the ISO specifications. RS232 voltages are higher than RS422 ones, so there is little likelihood of damage to an RS232 equipment by connecting it to Nimbus' RS422 port (provided that the connections are not inadvertently miswired). Nimbus itself is considered to be relatively robust. The RS422 port on Nimbus uses a small 6-wire "Bell" connector and a standard flat 6-wire cable. This is fully described in RML documentation, but not all cables/connectors comply with the description. The rest of this appendix assumes that the cable is inserted into the connector so that the blue wire is on the left, with the other 5 in the order yellow, green, red, black, white. This is as viewed with the plastic spring on your side of the connector, and the cable coming out of the bottom of the connector. If the cable has been inserted the other way round (and it is a 50/50 chance), then the following colour-interchanges should be (mentally) performed: blue <===> white yellow <===> black green <===> red The Nimbus RS422 provides only two signals, each using two wires. In principle these may be used to provide a simplex data channel (either sent or received) with a flow-control handshake in the opposite direction, or a duplex data-channel with no handshake or control signals. It is this limited full-duplex mode which is used by Kermit. Different pinning-out of the wires in the connecting cable is required for the three different modes of use. The duplex connection is provided if a standard Nimbus bell plug and 6-wire cable is connected to an RS232 25-pin plug with the following colour-coding: Green - Tx, RS232 pin 2 Red - Rx, RS232 pin 3 Yellow ) White ) - Both paralleled to RS232 pin 7 This is for a cable to a DCE (modem), i.e. no crossover of the data wires. If connection to another DTE (e.g. another micro) is required, the Tx & Rx wires should be crossed over. The other two wires carry the power-supply used in Piconet mode and should be left disconnected. Appendix II ----------- Current Restrictions. --------------------- There are a number of restrictions and infelicities in the current version of the program. Among those known are:- a. The 480Z IDC-version cannot hold DTR high during a disk transfer; the connecting cable must be wired to hold DTR high at the modem/mainframe/switch if this is needed. The Nimbus Aux version handles no control-lines at all. The control-line handling of the Nimbus Piconet version is not yet validated. b. There are no facilities for half-duplex or split-speed working. c. A few disk I/O errors (e.g. file locked) are not trapped effectively. On 480Z, either NDOS error-messages are displayed, or the Kermit program fails and returns control to CP/M. Under MSDOS, normal disk-error messages appear (in a different colour), but normal Kermit activity resumes if and when the problem has been solved. An extreme case of undiagnosed disk problems is that if the receiving disk is removed from a 480Z in mid-transfer, no error is sent to the mainframe. d. If a Mark I 480Z is in use, block-graphics characters are displayed in place of inverse-video ones at a few points. e. RML Kermit cannot act as a server. f. Flow-control is not yet implemented on Nimbus Kermit. g. The Piconet SIM generates errors when receiving data at 4800baud or above; it can transmit data (and receive the ACK/NAK packets) at up to 9600baud. h. Nimbus Kermit uses code for communications which is not yet integrated with the MSDOS drivers. After running Kermit it is necessary to reload MSDOS by CTRL-ALT-DEL; this should be done before attempting to load another program, otherwise it will be necessary to switch off the Nimbus power-supply to regain control. ********************************************************